前言

在這篇文章中，我們將介紹 Vue 提供的兩種 API 風格：選項式（Options API）與組合式（Composition API），這兩種寫法會影響開發時處理邏輯的方式，也會左右整體程式架構與後續維護策略。

在實務開發中，團隊往往會根據需求、過往專案的開發習慣或 Vue 版本的不同，選擇其中一種作為主要開發風格。因此，若能清楚了解兩種 API 的語法差異與設計理念，不僅能更快理解專案程式碼，也能在查閱官方文件📚或學習延伸套件教學時，對應到正確的使用方式。

這篇文章會分享兩種 API 的官方學習資源與核心概念，未來在面對不同類型的專案或閱讀他人程式碼時，能快速理解架構與技術選擇背後的考量。

最實用的步驟1. 要怎麼閱讀官方文件

先來看看要怎麼在官方文件中切換兩種不同的 API 風格。請先前往官方網站，接著在畫面左側找到 API 風格偏好（API Preference）選項，這裡就可以切換不同API風格。
切換後右側的主要內容（例如 程式碼範例、內文說明 等）也會自動更新，對應目前所選擇的風格。

（前往官方文件囉！ 圖片來源）

看完官方文件的基本介紹後，如果想練習看看，可以到導覽列找到 Docs 前往 Tutorial ，有 15 項練習範例教學，能帶我們快速認識 Vue 常見且核心的用法。

（下方編號介紹對應圖片中編號 圖片來源）

1. API Preference 功能介紹

• Options/Composition：可以切換兩種API風格。
• HTML/SFC：單一元件檔案切換為原始的HTML會呈現什麼樣子 (呈現位置 3. )。

2. 題目說明

介紹並說明如何完成這項練習範例，如果在過程中卡關，也可以按左下角「看答案!（Show me!）」按鈕來查看解答。
右上角的「文A」圖示可以切換語言，根據個人需求切換成方便閱讀的語言。

3. 程式碼內容

撰寫程式解答練習範例。

• Show Error：編輯器會即時檢查語法錯誤並跳出提示，不過在撰寫未完成時可能會出現預期中的錯誤訊息，如果覺得干擾，也可以先關閉這個功能。
• Auto Save：切換是否要自動儲存變更。若關閉自動儲存，仍可使用「CTRL + S」手動儲存，就像平常在編輯器中開發時一樣。

4. 即時預覽結果

可以透過預覽畫面立即檢查成果，看看最後有沒有寫對囉！如果寫錯也會跳提示。

完成 互動教程（Tutorial） 練習的差不多了，可以繼續前往「示例」複習更多用法。同樣可以透過API 風格偏好（API Preference）切換不同的 API 風格來閱讀程式碼。

（示例畫面 圖片來源）

初次認識 Vue 的兩種 API 風格

1. 選項式 API（Options API）

從區塊分明的開發方式開始。

Vue 的其中一種API風格，允許開發者透過定義一個選項物件來撰寫元件的邏輯。在選項物件中，元件的邏輯會被組織在不同的選項群組中，例如：

• data()：用來定義響應式和回傳物件的函式，物件中的屬性會被 Vue 代理到元件實例的 this 上。
• methods：用來宣告要掛在元件實例上的函式，會自動綁定到元件的 this，可以在生命週期鉤子裡呼叫，這些函式也可以作為模板中的事件處理器綁定。
• mounted()：Options API掛載階段的其中一種生命週期鉤子，會在元件掛載完成後被呼叫，其他關於生命週期鉤子更詳細的介紹可參考第十二篇。
• 其他選項還包括 props、emits、computed 等，用來定義元件外部可傳入的屬性、觸發的事件和計算屬性。

舉個簡單的Options API範例

<script>
	export default {
	    data() {
	        return {
	            count: 0
	        }
	    },
	    methods: {
	        incrementCount() {
	            this.count++
	        }
	    }
	}
</script>

這種 API 風格寫法和 Vue 2 幾乎一樣，但初始化的方式稍有不同。像是 data、methods、mounted 等選項物件，依然維持「分區管理」的寫法。白話來講就像是在填寫表單——Vue 已經幫妳準備好欄位與格式，我們只需要把資料填進對應的位置就可以了。
Options API 語意清楚、邏輯結構明確，對初學者友好相對容易理解與上手。在撰寫時，元件的邏輯會圍繞著「元件實例」的概念展開，並透過 this 這個關鍵字來存取元件中定義的資料與方法。
如果本身有 OOP 基礎的開發者，或曾經使用過 Vue 2 開發，這種寫法會比較直覺，因為 Options API 提供一種「類似 OOP 的 class 使用體驗」，以選項分類的結構化 API將響應式邏輯包裝在不同的選項內，並透過明確的欄位引導開發者組織程式碼。

(參考來源 Vue.js TypeScript 與 Options API、 Vue.js Which to Choose?)

2. 組合式 API（Composition API）

邏輯抽取更靈活的模組化寫法

Composition API 是 Vue 3 引入的另一組 API 風格，讓開發者能夠在 Vue 元件的 setup() 或 <script setup> 中，以函式化的方式直接撰寫邏輯，而非使用 Options API 的宣告式選項結構，包含響應式 API、生命週期鉤子、依賴注入等多種類型的 API。

• 響應式 API（ 例如 ref() 和 reactive() ），用於創建響應式狀態，搭配 computed() 實現計算屬性，以及 watch() 或 watchEffect() 創建偵聽器。
• 生命週期鉤子（ 例如 onBeforeMount() 和 onMounted() ），允許開發者在不同階段觸發，進行特定的操作。
• 透過 provide() 與 inject() 函式，讓開發者在 Composition API 中，能夠在不同組件間共享響應式狀態或方法，實現靈活的組件解耦與狀態傳遞。

舉個簡單的範例（Composition API + <script setup>）

<script setup>
	import { ref } from 'vue'
	
	const count = ref(0)
	
	function incrementCount() {
	    count.value++
	}
</script>

在 Composition API 的風格中，不需要再像 Options API 那樣把 data、methods、mounted 分開寫。它採用的是「基於函式的組合邏輯」，雖然不是函數式程式設計（Functional Programming），但它鼓勵開發者將相關邏輯集中在一起撰寫，讓程式碼的組織性更好，也更利於維護，尤其當元件變得複雜時，這種結構更能顯現優勢。

我們會在單一元件檔案（SFC）搭配 <script setup> 語法來使用，<script setup> 是一個語法糖（就是讓你少寫很多樣板的輔助寫法），它會使 Vue 編譯階段時自動轉換與優化程式碼，例如 變數、函式可以直接寫在檔案最上面，寫完就能在模板裡直接用，連 return 都不用寫，減少重複樣板（boilerplate）。像是在 <script setup> 中定義的變數或函式，能直接在模板中使用，不需要透過 return 或 this，簡化撰寫流程。
這種風格讓功能邏輯更模組化、集中管理，進而提升元件的可讀性與可維護性，特別適合大型專案或多人協作情境。

跟剛剛介紹的選項式 API 不同，組合式 API 不再是「填寫表單」照著欄位填寫資料的方式，而比較像是「組裝樂高積木」的感覺～透過 Vue 提供的函式去組裝元件資料與邏輯。把元件依照需求一塊塊拼湊起來，靈活又具彈性。

(參考來源 Composition API 常見問答、Vue.js TypeScript 與 Composition API)

Options API 與 Composition API 的優缺點整理

最後重點統整優缺點，資訊如下表格：

為什麼會有這兩種寫法，它們背後的特性是什麼？

這兩種 API 風格的產生反應了 Vue 在不同階段的設計考量和對應的優先順序，下面來分別來介紹它們各自的特性：

Options API的特性

• Options API是Vue早期設計的核心，主旨在提供一個容易理解與學習的程式設計模式。
• 用預先定義的選項將組件的邏輯、資料、方法等分開，強調了程式碼的組織性 (參考來源 與選項式 API 的關係)，對於小型至中型專案來說，這樣的結構已能提供良好的開發流程與架構。
• 對於那些習慣物體導向程式設計（OOP）類別概念的開發者來說，選項式 API 相對更容易上手。

Composition API的特性

• Composition API 的引入是為了解決 Options API 在處理大型、複雜專案時所面臨的限制，特別是在邏輯復用、程式碼組織和 TypeScript 支援方面，它的目的是提供允許強大的邏輯組織能力，開發者將相關的邏輯關注點聚集在一起，即使組件變得非常龐大，也能更保持程序碼的區別性和可維護性 (參考來源 更靈活的程式組織)。
• Composition API 採用以函式為主的寫法，讓 TypeScript 更容易判斷型別，不需要開發者自己手動標註太多型別。這樣可以寫出更穩定、更不容易出錯的程式碼，同時也能享受到 IDE（例如 VSCode 等）更完整的自動補全與錯誤提示功能 (參考來源 更好的類型推導)。
• 也讓「把程式裡相似的邏輯拿出來重複使用」這件事變得更簡單（例如 登入檢查不同元件都會用到 等）。Vue 的響應式系統也因為這樣變得更有彈性，能夠更容易跟第三方狀態管理庫（例如 Pinia 等）一起搭配使用上更順暢。 (參考來源 邏輯複用)。

Composition API 是一種更直接的應用，提供更靈活、可擴展的開發體驗。

總結來說，Vue 同時保留了這兩種風格，讓開發者可以依據專案規模和需求，選擇最合適的開發模式。雖然Options API設計風格較接近早期Vue版本的使用方式，但Vue官方也明確表示，並不會廢棄Options API的設計，選項式 API 依然是 Vue 不可或缺的一部份(參考來源 選項式 API 會被廢棄嗎？)。兩種API雖然風格不同，但它們實際上是基於相同的底層系統運行的，只是提供了不同的開發介面，所以兩種 API 風格都學起來也是不錯的選擇 (來個雙刀流不好嗎😏)。

實務2選1，該用哪一種寫法才好？

從開發團隊習慣、專案需求、擴充性與維護成本等角度出發去評估，這兩種API風格是採用同一種底層系統，只是寫法與串接函式的方法不同，假設公司開發團隊的專案，是要從Vue2開始重構或升級版本，建議可以採用Options API，這種API風格寫法上跟Vue2比較像。如果團隊是習慣自由的像平常寫JavaScript一樣，直接用變數、函式、模組來組織邏輯，且一個元件裡可能會同時處理很多不同的功能區塊那Composition API 會比 Options API 更適合做使用。

所以結論是：還是要看團隊的習慣還有專案規模與需求做決定！！ 理解了兩種API風格後，就可以好好地與團隊討論，選擇最適合目前專案需求的開發風格！

結語

在這篇文章中，我們一次掌握了 Vue 中兩種 API 的設計思維與寫法差異，也練習了如何從官方文件切換並閱讀不同風格的程式碼。在實務開發中，「能夠寫出功能」是第一步，更重要的是能依據專案需求，判斷「在什麼情境下，該採用哪一種做法」，不論選擇 Options API 還是 Composition API，每一種都代表著某種架構思維與溝通方式。
下一篇我們將說明如何建立「LINE Login」與「Messaging API」，一步一步往網站功能完成邁進吧！

參考資料與延伸閱讀

⑴ Vue 官方網站
⑵ 物件導向程式設計(OOP) 延伸參考來源
⑶ Vue.js TypeScript 與 Options API
⑷ Vue.js 官方介紹 Which to Choose?
⑸ Composition API 常見問答
⑹ Vue.js TypeScript 與 Composition API
⑺ 圖片說明 Tutorial 來源：vuejs
⑻ 圖片說明示例來源：vuejs